herein are included copies of:
copy included of main body of xanim264.txt:
XAnim Release 2.64.0 XAnim was written to display various types of animations in an X11 environment. It should support most display types and can be compiled on Unix and VAX/VMS machines. The intent was/is to develop a base player that allows new animation formats to be added as they are developed. You can generate a Makefile file from the Imakefile by typing xmkmf in the xanim directory or you can copy Makefile.unx to Makefile and edit that to choose to choose your favorite compiler, optimization flags and to indicate where the X11 libraries and includes are located. For VAX/VMS systems make.com, xanim.opt and descript.mms are provided. You can also edit the file xanim_config.h to setup up your favorite default conditions. Most of these can be overridden at run time. NEW TO REV 2.64 + Quicktime Animation support. + New option to have xanim read anim from file instead of loading into memory. + Fixed bug that prevented xanim from running on some Truecolor displays(SGI and Sun with rasterflex). Once compiled, xanim can display the following: 1) FLI anims. 2) FLC anims. 3) IFF animations. The following features are supported: -> Compressions 3,5,7,J(movies) and l(small L not 1). -> Color Cycling during single images and animations. -> Display Modes normal depth 1-8, EHB, HAM and HAM8. 4) GIF87a and GIF89a files. -> single and multiple images supported. -> GIF89a animation extensions supported. 5) a kludgy text file listing gifs and what order to show them in. 6) DL animations. 7) Amiga PFX(PageFlipper Plus F/X) animations. 8) Amiga MovieSetter animations(For those Eric Schwartz fans). NOTE: some of these are a must see. 9) Utah Raster Toolkit RLE images and anims. 10) AVI animations. Currently supported is -> Microsoft Video 1 (CRAM) depth 8 and 16. -> Raw depth 8 with colormap. 11) Quicktime animations. The following features are supported: -> Apple Graphics (RLE ) depth 1,8,16 and 24. -> Apple Animation (SMC ) depth 8. -> Apple Video (RPZA) depth 16. -> (RAW) depth 8. -> Supports multiple video trak's. -> Supports animations with multiple codecs. -> Supports flattened anims AND -> Supports separte .rsrc and .data forks. 12) any combination of the above on the same command line. Other features: 1) On the fly scaling of animations. 2) Option to use default cmap. 3) Merge the cmaps of several anims to prevent color flickering. 4) no buffer, buffer and pixmap options for speed/memory tradeoffs. 5) option to read animation from file instead of loading to memory. 6) looping and ping-pong options. 7) User selectable X11 Visual supported for Multi Visual Servers. 8) Timing options for benchmarking purposes. 9) Forwards/Backwards/single stepping from keyboard and mouse. 10) variable speed playback from keyboard. 11) Gamma adjustment to colormaps. Mark Podlipec podlipec@wellfleet.com
SYNOPSIS
xanim [ +Vnum ] [ +Ccopts ] [ +Ggopts ] [ +Mmopts ] [
+Ssopts ] [ +opts ] animfile [ [ +opts ] [ animfile ]
... ]
DESCRIPTION
XAnim is a program that can display animations of various
formats on systems running X11. XAnim currently supports the
following animation types:
+ FLI animations.
+ FLC animations.
+ IFF animations. The following features are sup-
ported:
-> Compressions 3,5,7,J(movies) and l(small L).
-> Color cycling during single images and anims.
-> Display Modes: depth 1-8, EHB, HAM and HAM8.
+ GIF87a and GIF89a files.
-> single and multiple images supported.
-> GIF89a animation extensions supported.
+ GIF89a animation extension support.
+ a kludgy text file listing gifs and what order to
show them in.
+ DL animations.
+ Amiga PFX(PageFlipper Plus F/X) animations.
+ Amiga MovieSetter animations(For those Eric Schwartz
fans).
+ Utah Raster Toolkit RLE images and anims.
+ AVI animations. Currently supported are
-> Microsoft Video 1 (CRAM) depth 8 and 16.
-> Raw depth 8 with colormap.
+ Quicktime Animations. The following features are
supported:
-> Apple Graphics (RLE ) depth 1,8,16 and 24.
-> Apple Animation (SMC ) depth 8.
-> Apple Video (RPZA) depth 16.
-> (RAW) depth 8.
-> Supports multiple video trak's.
-> Supports animations with multiple codecs.
-> Supports flattened anims
-> Supports separate .rsrc and .data forks.
+ any combination of the above on the same command
line.
XAnim also provides various options that allow the user to
alter colormaps, playback speeds, looping modes and can pro-
vide on-the-fly scaling of animations with the mouse.
OPTIONS
A + will generally turn an option on and a - will turn an
option off. This can be reversed at compile time. (see
xanim_config.h).
In each SubMenu the options should be run together with no
intervening spaces. A + or a - within a SubMenu will be an
exit from that submenu. Options will affect all animations
following the invocation of that option. Most options may be
changed in between animations without affecting previous
animations.
In the following sections, an num represents an integer
number and an fnum represents a floating point number. If a
floating point number is of an integer amount, the . need
not be specified. There should be no spaces between the
option and the numbers.
copts SubMenu for Color Options
+1 Create a colormap from the first frame of a
TrueColor anim and then remap the remaining
frames to this colormap. This can potentially
add significant time to the startup of an ani-
mation but usually results in better colors.
The animation needs to be buffered for this
option to work. Not valid for TrueColor or
DirectColor displays(nor is it needed).
+3 Convert TrueColor anims to 332(StaticColor).
TrueColor anims are animations that provide
separate RGB info for each pixel, rather than
each pixel being an index into a global color-
map. AVI(16bit CRAM), QT(RPZA and RLE depth 16
and 24) and URT RLE 24 bit anims are examples
of TrueColor anims. This option is ignored for
TrueColor or DirectColor displays.
+A Create a colormap from each frame of a
TrueColor anim. This can be useful if the
colors radically change during the course of
the animation. This can take a VERY,VERY long
time at start up. Animation must be buffered.
This option is ignored for TrueColor or
DirectColor displays.
+a Remap all images to single new cmap created
from all of the colormaps.
+d Use Floyd-Steinberg dithering if needed for
non-monochrome displays. This will cause a
reduction in playback speed.
+f Forcibly remap to all frames to 1st frame's
cmap.
+g Convert TrueColor anims to gray scale. This
option is ignored for TrueColor and DirectColor
displays.
+h Use histogram to aid in color reduction. His-
trogramming is only done on frames that are
buffered.
+m This option is currently needed if you want to
dither TrueColor anims to a 332 colormap. Ani-
mation must be buffered. Typically +bC3dm is
the option to use. This can take a VERY long
time at start up.
+n Don't create new colormap but instead allocate
colors from the X11 Display's default cmap.
gopts SubMenu for Gamma Options
+afnum Set gamma of animation to be displayed.
+dfnum Set gamma of display. 1.0 is no change. gamma's
greater than 1.0 typically brighten the anima-
tion.
mopts SubMenu for Median-Cut Quantization Options
+a compute box color from average of box.
+c compute box color as center of box.
+bnum Truncate rgb to num bits before quantizing.
sopts SubMenu for Scaling Options
+i Half the height of IFF anims if they are
interlaced.(Not completely reliable since not
all IFF anims correctly identify themselves as
interlaced).
+n Prevents X11 window from resizing to match
animations's size.
+r Allow user to resize animation on the fly.
Enlarging an animation can greatly reduce play-
back speed depending on the power of the cpu.
+sfnum Scale the size of animation by fnum before
displaying.
+hfnum Scale the horizontal size of the animation by
fnum before displaying.
+vfnum Scale the vertical size of the animation by
fnum before displaying.
+xnum Scale the animation to have width num before
displaying.
+ynum Scale the animation to have height num before
displaying.
+c Copy display scaling factors to display buffer-
ing factors.
+Sfnum Scale the size of the animation by fnum before
buffering it.
+Hfnum Scale the horizontal size of the animation by
fnum before buffering it.
+Vfnum Scale the vertical size of the animation by
fnum before buffering it.
+Xnum Scale the animation to have width num before
buffering it.
+Ynum Scale the animation to have height num before
buffering it.
+C Copy buffer scaling factors to display scaling
factors.
Normal Options
+b Uncompress and buffer images before displaying.
This only applies to AVI,QT, IFF,FLI,FLC anima-
tions. The rest(GIF87a,GIF89a,DL,PFX and RLE)
are currently always uncompressed and buffered.
This is cleared by the +f option.
+f Don't load anim into memory, but read each sec-
tion only when needed. This is supported only
for AVI,QT,IFF,FLI and FLC animations. This
option is cleared by the +b option. This saves
memory at the cost of speed.
+c let xanim know that iff anim is a nonlooping
one.
+dnum debug switch. num can be from 0(off) to 5(most)
for level of detail.
+F Floyd-Steinberg dithering when needed.
+jnum num is the number of milliseconds between
frames. if 0 then the time specified in the
animation is used for timing purposes.
+lnum loop animation num number of times before mov-
ing on to next animation.
+lpnum ping-pong animation num number of times before
moving on to next animation.
+N don't display images. Useful for benchmarking.
+o turns on certain optimizations. See
xanim.readme.
+p Use Pixmap instead of Image in X11. This option
has no effect if the animation is
buffered(either by default or with the +b
option).
+r Allow color cycling for IFF single images.
+R Allow color cycling for IFF anims. (default
should be off)
+T0 Title option 0. Title is just XAnim.
+T1 Title option 1. Title is current anim name.
When anim is stopped, the current frame number
is included.
+T2 Title option 2. Title is current anim name and
current frame number.
+v Verbose mode. Gives some information about ani-
mation such as size, number of frames, etc.
+Vnum Select X11 Visual to use when displaying anima-
tion. The num is obtained by using the +X
option of xanim.
+Vclass Select the best X11 Visual of Class class when
displaying the animation. class can be anyone
of the following strings and is case insensi-
tive. (ie StaTicGraY is same as staticgray).
staticgray Select best StaticGray Visual.
grayscale Select best GrayScale Visual.
staticcolor Select best StaticColor Visual.
pseudocolor Select best PseudoColor Visual.
truecolor Select best TrueColor Visual.
directcolor Select best DirectColor Visual.
+X X11 verbose mode. Display information about the
support X11 visuals.
WINDOW COMMANDS
Once the animation is up and running there are various com-
mands that can be entered into that animation window from
the keyboard.
q quit.
Q Quit.
g Stop color cycling.
r Restore original Colors(useful after g).
w Restore original window size(useful after resiz-
ing).
Toggle. starts/stops animation.
, Single step back one frame.
. Single step forward one frame.
< Go back to start of previous anim.
> Go forward to start of next anim.
m Single step back one frame staying within anim.
/ Single step forward one frame staying within anim.
- Increase animation playback speed.
= Decrease animation playback speed.
0 Reset animation playback speed to original values.
MOUSE BUTTONS
Once the animation is up and running the mouse buttons have
the following functions.
Single step back one frame.
Toggle. starts/stops animation.
Single step forward one frame.
BUFFERING, PIXMAPS and READ_FROM_FILE Options
XAnim by default will read the entire animation into memory.
DL, PFX, Moviesetter, GIF or URT RLE type animations are
always uncompressed and stored in memory as individual
images.
For the AVI, QT, IFF, FLI/FLC animations, only the
compressed delta is stored. These deltas are then
uncompressed each time they need to be displayed. The buffer
option(+b) may be used to potentially speed up playback by
uncompressing and storing these images ahead of time. But
more memory is used up in the process.
When an XPutImage is called, the image typically gets copied
twice, once to memory and then from there onto the display.
A pixmap is directly copied onto the display without the
first copy. This is why it is sometimes much faster to use
the pixmap option(+p). Each image isn't converted into a
pixmap until the first time it is displayed. This is why the
first loop of an animation using this option is sometimes
slower than subsequent loops. While the pixmap option may
improve playback speed, it will slow things down if on-the-
fly scaling needs to be performed. This is because XAnim no
longer has direct access to the image and needs to get a
copy of it before it can be scaled.
The read from file option(+f) causes xanim not to store the
compressed deltas in memory. Instead as each image is to be
displayed, xanim reads the corresponding compressed delta
from the file, expands it and then displays it. While this
can dramatically cut down on memory usage, the necessary
reads from disk(or whatever) can slow down playback speed.
XAnim still needs to allocate one to three image buffers
depending on the type of animation and the scaling options
used. This option is only supported for AVI, QT, FLI/FLC and
IFF animations. The BODY chunk of IFF animations is not
included in this. As a result, an IFF animation that is made
up of several BODY chunks will not currently benefit from
this option.
SCALING Options
There are two sets of scaling options. One set, the display
scaling factors, affects the size of the animation as it is
displayed. The other set, the buffer scaling factors, affect
the size of the images as they are stored in
memory(buffered). The buffer scaling factors only affect
animations that are buffered and can greatly increase or
decrease memory usage.
These two sets are completely independent of each other. You
can set the buffer scaling factors to 20 times the normal
animation size and not affect the size at which that anima-
tion is displayed. The images are stored at 20 times the
normal size(and at 400 times the memory usage), but then get
scaled back down to normal size before being displayed.
NOTE: that an animation must be buffered in order for the
buffer scaling factors to have any affect on it. The display
scaling factors affect all animations.
You can create pixellation like affects by buffering the
animation at 1/8 it's normal size, but keeping the display
scaling factors at the original size. (IE "xanim +bSS0.125
anim.anim").
Many times it's faster to store and display an animation
with large dimensions at half-size. The option "+bSS0.5C" or
"+bSS0.5s0.5" both will accomplish this. To save memory, you
could even store the animation at half size and yet display
it at full size. "+bSS0.5" will accomplish this.
FORWARDS, BACKWARDS and OPTIMIZATION.
Many type of animations(FLI/FLC/IFF/some AVI and QTs) are
compressed with forward playback in mind only. Each delta
only stores the difference between the current frame and the
previous frame. As a results, most of these animations don't
display correctly when played backwards. Even when buffered
up, these may not work, since XAnim only stores the smallest
rectangle that encompasses the changes from the previous
frame. You can force XAnim to store the entire frame by
specifying the "-o" option to turn this optimization off.
This will most likely use more memory and slow down the ani-
mation, since more of the image needs to be stored and/or
displayed.
COLOR OPTIONS
Most of this will be a TBD for a future rev and what's here
might be sketchy, incomplete or just plain confusing.
TrueColor and DirectColor displays don't need to worry about
most of these options, as the animations can be displayed in
their original colors(ignoring monitor variations etc). How-
ever, TrueColor and DirectColor displays can't display
animations that employ color cycling techniques where the
colormap changes from frame to frame. DirectColor could
potentially support this, but not TrueColor.
For the rest of the displays, the problem becomes matching
the colors in the animations to the available colors of the
Display. For most PseudoColor displays this means 256
colors. Many of which are already in use by various other
programs. XAnim defaults to creating it's own colormap and
using all the colors from that. The window manager then
installs this new colormap, whenever the mouse pointer is
inside the XAnim animation window(Sometimes a specific
action is required to change the ColorMap Focus, like click-
ing in the window or pressing a specific key). In any case,
this action usually causes all the other colors on the
screen to be temporarily "messed-up" until the mouse is
moved out of the animation window. The alternative, is to
use the "+Cn" option. Now XAnim tries allocating all the
colors it needs from the current colormap. If it can't get a
certain color, then XAnim choose one that is "close" to this
certain color. Close is completely arbitrary. The animation
is now displayed in colors that are different than the ori-
ginal colors. This difference may or may not be noticeable.
Another big problem is when the animations are what I called
TrueColor animations. Where each pixel is stored as RGB tri-
plets. For example, AVI 16 bit CRAM animations. Each pixel
has 5 bits of Red, 5 bits of Green and 5 bits of Blue info
associated with it. This means there can be up to 32768
unique colors in each image. And on most PseudoColor
displays we can only display 256 unique colors. Beside get-
ting better displays, what can we do? XAnim defaults to
truncating the RGB information from 555 to 332. That is to 3
bits of Red, 3 bits of Green and 2 bits of Blue. Less on
Blue because the human eye is more sensitive to Red and
Green than Blue. This 332 colormap happens to be 256 colors
in size, which nicely fits in with our display. If our
display only had 64 colors, then XAnim is smart enough to
truncate things down to 222. Now the problem is the colors
of the displayed anim are noticeably different than the ori-
ginal colors. Typically you can see color banding etc.
While this is fine to get a feel for the animation, we can
do better. One of the solutions XAnim currently offers is
the "+bC1" option. What this does is choose the the best 256
colors from the first image of the animation. Then each
pixel of each subsequent image is remapped to one of these
256 colors. This takes up some CPU time up front and more
memory since each image needs to be buffered, but results in
a colors that are closer to the originals. Another option,
"+bCA", chooses the best 256 from each image, then 256
colors from all these colormaps are chosen as the final
colormap. This is useful if the colors in the first image
aren't representative of the rest of the animation. This can
be very slow. Another option that is supported, but not
really optimized for yet is "+bC3dm". This causes XAnim to
use a 332 colormap and then apply a Floyd-Steinberg dither
algorithm to each image. Currently this is very slow. Dif-
ferent dithers(like Ordered) and better optimizations might
speed this up in future revs. In general, handling of
TrueColor animations in XAnim needs to be improved.
Another scenario where colors need to be remapped, is when
several images or animations with different colormaps need
to be displayed. Changing the colormap usually results in
an annoying flicker. One solution to this is to remap all of
the images/animations to the same colormap. The "+Ca" option
chooses the best colors from all the colormaps and then
remaps all the images to it. The "+Cf" option, simply remaps
everything to the first colormap. The "+Ch" option is use-
ful when an animation's colormap specifies a lot of colors
that aren't used. XAnim looks through each buffered image of
the animation and makes a histogram of the useage of each
color. This information is then used to weedout unused or
rarely used colors.
QUICKTIME ANIMATIONS
Quicktime animations are usually stored in two separate
files. One is call a data fork and ends with a ".data". The
other is a resource fork and ends in a ".rsrc". Sometimes
these animations are in a "flattened" format, where every-
thing is put into one file. There's no standard naming for-
mat for these types of files.
For example, if you have a quicktime animation made up of
two files named: "spin.rsrc" and "spin.data", you can
display them using Xanim with either of the following com-
mands "xanim spin" or "xanim spin.rsrc". XAnim is smart
enough to add/modfiy the ".rsrc" and ".data" endings as
needed.
For "flattened" quicktime animations, you need to specify
the entire file name.
NOTE: XAnim may not support all SMC or RPZA quicktime anima-
tions. It'll print "unknown code variation XX" to the screen
as it encounters these and move on to the next image of that
animation.
EXAMPLES:
To display a single animation:
xanim iff3.anim
To display a nonlooping IFF animation:
xanim +c iff3.anim
To display A.fli 3 times, B.anim and C.movie 2 times each and D.fli
once before repeating:
xanim -l3 A.fli -l2 B.anim C.movie -l1 D.fli
To see A.anim real slow(2 seconds for each frame):
xanim +j2000 A.anim
To display title image for a while then run an animation at
normal speed:
xanim +j2000 title.gif +j0 anim.gifanim
A series of GIF's can be displayed as:
xanim im_0.gif im_1.gif im_2.gif ... im_36.gif
or
xanim im_*.gif
or
xanim im.txt
or
xanim im.gifanim
where im.txt is a txt file(a list of images, see xanim.doc for more details).
and im.gifanim is one gif file composed of im_0.gif through im_36.gif.
(see txtmerge to create a single gif file from a txt file).
X11 Notes:
--------------------------------------
I. X11 Server Options
When XAnim opens the display it passes the argument list to X11 which
then filters off the arguments it recognizes. XAnim won't even see these
arguments(which is sometimes a problem). For instance
xa -geom =+100+100 skier.fli
will play the anim skier.fli at pos <100,100> on the X11 screen. Or
xa -display nantucket:0.0 skier.fli
will display the anim skier.fli on the machine nantucket's display.
Sometimes this is a problem, because a valid XAnim option is stripped by the
X11 server. For instance if +r was being stripped, then use ++r instead.
Same goes with -r. Use --r instead if you believe it's being filtered
by X11.
Machine Specific and Compiler Notes:
--------------------------------------
Some PC's need you to uncomment the line below in Makefile.
#OTHER_LIBS = -linet
Depending on your window manager(mwm,uwm,olwm,twm etc), you might
want to have XAnim do a XInstallColormap. This shouldn't be necessary
for most workstations and can cause core dumps on some PCs.
There are usually user selectable options for each window manager
that selects the colormap focus policy(pointer,fixed,explicit etc).
Use -DNO_INSTALL in Makefile if you DON't want XAnim to install
the colormap.
Some X11's don't have support for multiple visuals. An executable
compiled with such an X11 will not be able to correctly run on a
machine that does supports multiple visuals even if they're binary
compatible.
Hugh D.R. Evans has supplied make.com, xanim.opt and added VMS defines
so that VMS users may compile and run XAnim. Rick Dyson has provided
the descript.mms file and some VMS fixes. John Kneitz has also
provide some VMS fixes and suggestions.
Mark Podlipec podlipec@wellfleet.com
This describes(rather roughly) the animation types supported and some
of their special features. It's more of an organized rambling but
might give insight into what's going on.
FLI/FLC Animations:
FLI is by Autodesk Animator for the PC's. Support is for the 320x200
images. The file is composed of a series of images and deltas(a delta
is data that can generate the next image given a previous image) to
be played in sequence. An FLI animation can also change the color map
during the anim. FLC's have a few additional chunks and has support
for larger image sizes.
IFF Animations and Images:
IFF files were developed for the Amiga. Sound chunks are currently
ignored. Most IFF Animation files are meant to be double buffered.
The deltas refer not to the previous image, but the image before the
previous(two back). I know of 11 types of compressions 0 thru 8, J,
l and scala 32.
I've only included types 3, 5, 7, J and l because those are the only
ones I could test. The J type compression has an ANSI chunk at the
end which includes the order in which the deltas are to be applied
and they can be used more than once. Type l (small L) type anim is
also supported in revs 229 and higher. It's a compression type I've only
found in older animations.
IFF animations can be looping or non-looping. Looping means the last
two deltas produce images that are the same as the 1st two images. To
continuously loop an animation, you would not jump back to the beginning
but to the 2nd image instead. In order to loop non-looping animations
you would need to jump to the 1st image. There's no way to know ahead
of time which is which so the default is looping and if you have a
non-looping animation use the -c switch.
The Amiga has a couple of weird display modes, EHB and HAM. XAnim fully
supports EHB animations. HAM can produce 4096 colors(4 bits each red,
green, and blue) from 6 bits per pixel. One True and Direct Color
displays this is no problem. On lesser display, you have your choice
of 332 or Grayscale. 332 means the 8 bits(for 256 color display, less
for others) is divided into 3 bits of red, 3 bits of green and 2 bits
of blue and the HAM images are mapped to fit.
Surprisingly enough, it's not too bad for most anims.
NOTE: HAM8 is recently out and that is supported the same way.
IFF supports color cycling chunks that specify color ranges to be
cycled at specified intervals. Since there's no obvious end to this
type of animation, I just display the image for a set interval(see
xanim_config.h) and then move on. Early Amiga software totally
screwed up by saving color cycling chunks enabled in a lot of
images that were never meant to be cycled. This goes for animations
as well.
Single IFF images are supported as well. Uncompressed and
compression type 1 are supported. (XAnim makes use of the public domain
unpacker routine by Jerry Morrison and Steve Shaw). see unpacker.c.
GIF Images/Animations.
The GIF file consists of a screen color map and then a series of images,
each with their own optional color map. The images don't have to be at
the origin and can be any size smaller than the screen size. This allows
GIF animations to be created that only update the part of the screen
that changes. I don't have a program that does this yet but txtmerge is
a step in that direction. Also the GIF89a spec has included some extensions
that are animation specific. Rev 2.29.1 and up has limited support for
these. Comment fields in GIF files are displayed if you use the -v (verbose)
option.
GIF images are automatically uncompressed when read in. This might
change in the future.
TXT files
Probably should be called something else. Basically it is a ascii text
file that lists a number of GIF files to be displayed. Optionally, you
can specify the sequence the files are displayed in. Comments aren't
supported. I need to put a lot of work and thought into improving this
one.
TXT format needs to have txt91 as the 1st 5 characters in the file.
Following that there are a series of fields. Fields just have to be
separated from each other by white space. No extraneous characters
(ie comments) are supported, yet.
txt91 <--- header so XAnim knows what kind of file it is
4 <--- number of GIF filenames that follow
a.gif <--- gif file to be read in. 1st file is number 0.
b.gif
c.gif
d.gif
6 <--- number of frames that follow.
0 1 2 3 <--- display images in this order.
2 1
The sequence will be a.gif b.gif c.gif d.gif c.gif b.gif. Most likely
this anim will be looped and the last b.gif will flow smoothly into
a.gif as it starts over.
I like to improve upon this by adding timing and specialty fade/wipes.
Also it'd be nice if images could be unloaded and load on the fly to
conserve memory. If this happens it'll probably be a different format.
DL files
I only threw these in because it was easy and intense pressure from
friends. As far as I know, they come in three resolutions, 320x200,
160x100 and 80x50. They consist of a series of images with a frame
list at the end that gives the order they are displayed in. The frame
list also specifies nested looping of images. There's also a field for
Author and Title that is displayed if you specify
-v (verbose) option.
PageFlipper Plus F/X Amiga files
A series of deltas with a play list at the end. Supports color
map changes, nested loops and dynamic timing.
GoldDisk MovieSetter Animations.
Probably the most flexible animation format I've seen. Animations are
stored as a bunch of backgrounds, sounds and sets. Sets are smaller
images that get placed on top of the background(with transparent pixels).
A frame list at the end that describes each frame. Each frame
specifies which background to use(backgrounds can also scroll in
different directions and speeds), and a list of sets to put on that
background with depth information so characters can pass behind or
in front of each other. Sound information if contained here as well
to sync it up to the action. There is also color cycling and specialty
fades and wipes.
NOTE: This animation can come as one file or as three directories
and a control file. The three directories are usually Moviesets,
Moviebacks and Moviesounds. You might have to create the links
moviesets -> Moviesets and moviebacks -> Moviebacks or vice-versa
because the Amiga is case insensitive. Sounds are ignored for now.
Eric Schwartz has created several of these animations that are
worth checking out.
AVI Animations.
TBD
Quicktime Animations.
TBD
Mark Podlipec podlipec@wellfleet.com
OR, ...